Hierarchical parking assistance by connected vehicles

ABSTRACT

A method includes receiving from a vehicle, a position of the vehicle, obtaining locations of one or more available parking spaces from a plurality of parking spaces based at least in part on the position of the vehicle, determining an estimated travel time for the vehicle to arrive at each of the one or more available parking spaces based at least in part on the position of the vehicle and the locations of the one or more parking spaces, obtaining historical usage data for the one or more available parking spaces, and determining a probability that one or more of the available parking spaces will be available at a time when the vehicle arrives at each of the available parking spaces based at least in part on the estimated travel time and the historical usage data.

TECHNICAL FIELD

The present specification relates to systems and methods for assistingdrivers in finding parking spaces, and more particularly, tohierarchical parking assistance by connected vehicles.

BACKGROUND

Parking availability information is beneficial to drivers who arelooking for available parking in a garage, parking lot, or streetparking. Some garages or parking lots have sensors installed to monitoravailable parking spaces in the parking garages and parking lots, and toprovide available parking space information to drivers by displaying theinformation at the entrance of the parking garages or the parking lots,or changing lights installed above the parking spaces, respectively.However, installation of the monitoring system is not only expensive butalso time consuming. Accordingly, more efficient and less expensive waysof monitoring parking spaces is needed.

SUMMARY

In one embodiment, a method includes receiving from a vehicle, aposition of the vehicle, obtaining locations of one or more availableparking spaces from a plurality of parking spaces based at least in parton the position of the vehicle, determining an estimated travel time forthe vehicle to arrive at each of the one or more available parkingspaces based at least in part on the position of the vehicle and thelocations of the one or more parking spaces, obtaining historical usagedata for the one or more available parking spaces, and determining aprobability that one or more of the available parking spaces will beavailable at a time when the vehicle arrives at each of the availableparking spaces based at least in part on the estimated travel time andthe historical usage data.

In another embodiment, a system includes a plurality of first levelmanagers and at least one second level manager. Each of the first levelmanagers manages a parking facility. The second level manager is in ahigher hierarchical level than the first level managers. The secondlevel manager manages a locality. Each of the first level managers isconfigured to receive sensor data from one or more vehicles within theparking facility managed by the first level manager and position datacorresponding to a position of each of the vehicles within the parkingfacility. The parking facility has a plurality of parking spaces. Thesecond level manager is configured to receive facility parkingavailability data from one or more of the first level managers in thelocality managed by the second level manager. A first frequency of thefirst level managers receiving the sensor data from the vehicles ishigher than a second frequency of the second level manager receiving thefacility parking availability data from the first level managers.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments set forth in the drawings are illustrative and exemplaryin nature and not intended to limit the disclosure. The followingdetailed description of the illustrative embodiments can be understoodwhen read in conjunction with the following drawings, where likestructure is indicated with like reference numerals and in which:

FIG. 1 schematically depicts a hierarchical system for providing parkingassistance, according to one or more embodiments shown and describedherein;

FIG. 2A schematically depicts the hierarchical system for providingparking assistance of FIG. 1, according to one or more embodiments shownand described herein;

FIG. 2B depicts an exemplary map of a parking facility managed by asection manager of the system of FIG. 1;

FIG. 2C depicts an exemplary map of a locality managed by a localitymanager of the system of FIG. 1;

FIG. 2D depicts an exemplary map of a region managed by a city managerof the system of FIG. 1;

FIG. 3 depicts a schematic diagram of an exemplary section manager ofthe system of FIG. 1, according to one or more embodiments shown anddescribed herein;

FIG. 4 depicts a schematic diagram of an exemplary locality manager ofthe system of FIG. 1, according to one or more embodiments shown anddescribed herein;

FIG. 5 depicts a schematic diagram of an exemplary city manager of thesystem of FIG. 1, according to one or more embodiments shown anddescribed herein;

FIG. 6 depicts a flowchart for a method that may be implemented by thesection manager to identify available parking spaces in a parkingfacility, according to one or more embodiments shown and describedherein;

FIG. 7 depicts a flowchart for a method that may be implemented by thelocality manager to determine the number of parking spaces available ineach parking facility in a locality, according to one or moreembodiments shown and described herein;

FIG. 8 depicts a flowchart for a method that may be implemented by thecity manager to determine the number of parking spaces available withineach locality in a region, according to one or more embodiments shownand described herein;

FIG. 9 depicts a flowchart for a method that may be implemented by thesection manager to provide parking assistance, according to one or moreembodiments shown and described herein;

FIG. 10 depicts a flowchart for another method that may be implementedby the section manager to provide parking assistance, according to oneor more embodiments shown and described herein;

FIG. 11 depicts a flowchart for a method that may be implemented by thelocality manager to provide parking assistance, according to one or moreembodiments shown and described herein;

FIG. 12 depicts a flowchart for a method that may be implemented by thecity manager to provide parking assistance, according to one or moreembodiments shown and described herein; and

FIG. 13 depicts an exemplary parking route guidance that may be providedby the section manager, according to one or more embodiments shown anddescribed herein.

DETAILED DESCRIPTION

The embodiments disclosed herein include systems and methods forproviding parking assistance to drivers. Parking assistance may beprovided by various hierarchical level managers (e.g., section managers,locality managers, city managers, and the like) of a parking assistancesystem. A section manager may manage a single parking facility. Alocality manager may manage a locality containing a plurality of sectionmanagers and may be in a higher hierarchical level than the sectionmanagers. A city manager may manage a region containing a plurality oflocality managers and may be in a higher hierarchical level than thelocality managers.

As one or more vehicles travel through a parking facility, the vehiclesmay have sensors that collect sensor data. The sensor data may betransmitted to a section manager managing the parking facility. Thesection manager may use the sensor data received from the vehicles toidentify one or more available or unoccupied parking spaces in thefacility. In some examples, the vehicles may locally analyze the sensordata to extract one or more features. The vehicles may then transmitthese extracted features to the section manager. The section manager maythen use the features received from the vehicles to identify one or moreavailable parking spaces in the facility. Transmission of extractedfeatures rather than raw sensor data may minimize communicationoverhead.

A vehicle may also request parking assistance from the section manager.In response to such a request, the section manager may predict whichavailable parking spaces in the facility will be available at a timewhen the vehicle would arrive at the parking spaces. The section managermay then recommend an available parking space to the vehicle and guidethe vehicle to that parking space. The section manager may transmit atotal number of available parking spaces within the parking facility toa locality manager.

A locality manager may receive parking availability data from eachsection manager within the locality managed by the locality manager.Thus, the locality manager may maintain a record of the number ofparking spaces available at each associated parking facility within thelocality at any given time.

A vehicle may request parking assistance from the locality manager. Inresponse to such a request, the locality manager may predict the numberof available parking spaces there will be at each parking facility at atime that the vehicle would arrive at each parking facility. Thelocality manager may then recommend a parking facility to the vehicleand guide the vehicle to the facility. The locality manager may transmita total number of available parking spaces within the locality to a citymanager.

A city manager may receive parking availability data from each localitymanager within the region managed by the city manager. Thus, the citymanager may maintain a record of the number of parking spaces availablewithin each associated locality within the region at any given time.

A vehicle may request parking assistance from the city manager. Inresponse to such a request, the city manager may predict the number ofavailable parking spaces there will be within each locality at a timethat the vehicle would arrive at each locality. The city manager maythen recommend a locality to the vehicle and guide the vehicle to thelocality.

FIGS. 1 and 2A schematically depict a hierarchical system 100 forproviding parking assistance to vehicles, according to one or moreembodiments shown and described herein. In embodiments, the system 100comprises multiple levels of managers. For example, as shown in FIG. 1,the system 100 comprises three levels: a first level 110, a second level120, and a third level 130. In some embodiments, the system 100 maycomprise more than or less than three levels. The hierarchical structureof the system 100 allows for an ease of scalability of the system, asexplained below.

The first level 110 may include a plurality of first level managers, forexample, section managers 112. The first level 110 may include anynumber of section managers 112 (e.g., in the example of FIG. 1, thereare in section managers, S1 through Sin). Each section manager 112manages parking assistance for a section. In the illustrated example,each section manager 112 manages parking assistance for a single parkingfacility (e.g., a parking garage) associated with the section manager112. In other examples, one or more section managers 112 may manageparking assistance for other types of sections (e.g., multiple parkingfacilities, one or more floors of a parking garage, an area of streetparking, or the like).

The section managers 112 may be edge computing devices or edge servers,such as road side units. Each section manager 112 may be an edge serverlocated within or near the parking facility it is associated with. Inone example, one or more of the section managers 112 may be hosted by acloud server in a remote data center. In another example, one or morevehicles in a parking facility may be equipped with a vehicle-to-vehicle(V2V) communication module and the section manager 112 associated withthe parking facility may be hosted by the vehicles in the parkingfacility. In this example, the vehicles may share collected data witheach other over V2V communications to collaboratively perform theoperation of the section manager 112 described below.

Each of the section managers 112 may receive sensor data from one ormore vehicles within an associated parking facility. For example, FIG.2A shows a portion 200 of a parking facility with vehicles 202 and 204driving through the facility. The vehicles within the parking facilitymay transmit sensor data to the section manager 112.

The section manager 112 may use this received sensor data to identifyavailable parking spaces within the associated parking facility and maymaintain a record and/or a map of available parking spaces, as explainedin further detail below. FIG. 2B shows an exemplary map 210 of availableparking spaces within a parking facility that may be maintained by asection manager 112. The section managers 112 may also provide parkingassistance for vehicles within an associated parking facility.Specifically, a section manager 112 may guide a vehicle to an availableparking space within a parking facility, as explained in further detailbelow.

By limiting the scope of each section manager 112 to a single parkingfacility, the system 100 is able to provide fine-grained parkingguidance to individual parking spaces. That is, each section manager 112may be an edge computing device that only tracks parking availabilityfor a single parking facility. This may allow the edge computing deviceto quickly respond to vehicle requests for parking assistance withoutneeding to store parking availability data from multiple parkingfacilities. Because the section managers 112 track the availability ofindividual parking spaces within a parking facility, the data in thesection managers 112 may be refreshed and updated frequently (e.g.,every few seconds). This allows vehicles seeking parking assistancewithin a parking facility to receive accurate, near real-time guidance.

Referring back to FIG. 1, the second level 120 may include a pluralityof second level managers, for example, locality managers 122. The secondlevel 120 may include any number of locality managers 122 (e.g., in theexample of FIG. 1, there are k locality managers, L1 through Lk). Eachlocality manager 122 manages parking assistance for a locality (e.g., asmall geographic area), which contains one or more parking facilities orsections, each managed by a section manager 112. For example, FIG. 2Cshows a map 220 of a locality, which may be managed by a localitymanager 122, that contains parking facilities 222, 224, 226, and 228.The parking facilities 222, 224, 226, 228 may each be managed by asection manager 112. Any number of section managers 112 and associatedparking facilities may be located within each locality managed by thelocality managers 122 and each section manager 112 and its associatedparking facility is located within one locality managed by one localitymanager 122.

The section managers 112 within a locality may transmit parkingavailability data to the locality manager 122 that manages the locality.The parking availability data received by the locality manager 122 fromthe section managers 112 may comprise the number of parking spacesavailable within each parking facility managed by an associated sectionmanager 112 at a given time. The locality manager 122 may use thereceived parking availability data to maintain a record of the number ofavailable parking spaces in each parking facility within the associatedlocality at any given time. The locality manager 122 may use this recordof parking availability data to guide vehicles to a less congestedparking facility within the locality, as explained in further detailbelow.

Because each locality manager 122 only tracks the number of availablespaces within parking facilities rather than a detailed record of everyavailable space in each facility, the locality managers 122 may respondquickly to vehicle requests without the need to store an excessiveamount of data. This helps improve scalability of the system 100.

The parking availability data in the locality managers 122 may also berefreshed and updated less frequently than the section managers 112(e.g., every few minutes). This is because the locality managers 122aggregate parking availability data across an entire locality. As such,small errors in the number of available parking spaces may only have amarginal impact on the performance of the system 100.

Referring back to FIG. 1, the third level 130 may include a plurality ofthird level managers, for example, city managers 132. The third level130 may include any number of city managers 132 (e.g., in the example ofFIG. 1, there are n city managers, C1 through Cn). Each city manager 132manages parking assistance for a region (e.g., a large geographic areasuch as a city or city district), which contains one or more localitieseach managed by a locality manager 122. For example, FIG. 2D shows a map230 of a region, which may be managed by a city manager 132, thatcontains localities 232, 234, 236, and 238. The localities 232, 234,236, 238 may each be managed by a locality manager 122. Each of thelocalities 232, 234, 236, and 238 may contain one or more parkingfacilities, which may each be managed by a section manager 112.

The locality managers 122 within a region may transmit parkingavailability data to the city manager 132 that manages the region. Theparking availability data received from the locality managers 122 maycomprise the number of available parking spaces within the localitymanaged by each locality manager 122 at a given time (e.g., theaggregate number of parking spaces available in all of the parkingfacilities within the locality). The city manager 132 may use thereceived parking availability data to maintain a record of the number ofavailable parking spaces within each locality within the associatedregion at any given time. The city manager 132 may use this record ofparking availability data to guide vehicles to a less congested locality(e.g., a locality where drivers may utilize park-and-ride or publictransportation to arrive at their final destination) within the region,as explained in further detail below.

Because each city manager 132 only tracks the number of available spaceswithin each locality in the region rather than the number of availableparking spaces within each parking facility in the region, the citymanagers 132 may respond quickly to vehicle requests without the need tostore an excessive amount of data. This helps improve scalability of thesystem 100.

The parking availability data in the city managers 132 may also berefreshed and updated less frequently than the locality managers 122(e.g., every few hours). This is because the city managers 132 areaggregating parking availability data across an entire region. As such,the exact number of parking spaces available in each locality may not beneeded to ensure satisfactory operation of the system 100 as long as acoarse estimate is available.

While the system 100 of FIG. 1 is shown as having three levels, thesystem 100 may be extended to additional levels if further scalabilityis desired. For example, a fourth level may include one or more fourthlevel managers that receive parking availability data from the citymanagers 132. The system 100 may continue to be extended to any numberof hierarchical levels. In some examples, multiple managers may behosted on the same server or computing device. For example, a sectionmanager 112 and a locality manager 122 may be located on a singleserver. Alternatively, in another example, a locality manager 122 andcity manager 132 may be located on a single server.

Referring now to FIG. 3, the section manager 112 comprises one or moreprocessors 302, one or more memory modules 304, network interfacehardware 306, and a communication path 308. The one or more processors302 may be a controller, an integrated circuit, a microchip, a computer,or any other computing device. The one or more memory modules 304 maycomprise RAM, ROM, flash memories, hard drives, or any device capable ofstoring machine readable and executable instructions such that themachine readable and executable instructions can be accessed by the oneor more processors 302. The communication path 308 provides signalinterconnectivity between various modules of the section manager 112.

The network interface hardware 306 can be communicatively coupled to thecommunication path 308 and can be any device capable of transmittingand/or receiving data via a network. Accordingly, the network interfacehardware 306 can include a communication transceiver for sending and/orreceiving any wired or wireless communication. For example, the networkinterface hardware 306 may include an antenna, a modem, LAN port, Wi-Ficard, WiMax card, mobile communications hardware, near-fieldcommunication hardware, satellite communication hardware and/or anywired or wireless hardware for communicating with other networks and/ordevices. In one embodiment, the network interface hardware 306 includeshardware configured to operate in accordance with the Bluetooth®wireless communication protocol. The network interface hardware 306 ofthe section manager 112 may transmit and receive data to and from one ormore vehicles within the parking facility associated with the sectionmanager 112 and may transmit data to the locality manager 122 managingthe locality in which the section manager 112 resides.

The one or more memory modules 304 include a database 310, a parkingspace recognition module 312, a travel time estimation module 314, ahistorical usage data acquisition module 316, a parking availabilityprobability determination module 318, a parking space selection module320, and a route guidance module 322. Each of the database 310, theparking space recognition module 312, the travel time estimation module314, the historical usage data acquisition module 316, the parkingavailability probability determination module 318, the parking spaceselection module 320, and the route guidance module 322 may be a programmodule in the form of operating systems, application program modules,and other program modules stored in one or more memory modules 304. Insome embodiments, the program module may be stored in a remote storagedevice that may communicate with the section manager 112. Such a programmodule may include, but is not limited to, routines, subroutines,programs, objects, components, data structures and the like forperforming specific tasks or executing specific data types as will bedescribed below.

The database 310 may temporarily store data received from one or morevehicles in the associated parking facility. The data received from theone or more vehicles may include sensor data and position data from thevehicles. The parking space recognition module 312 may use thisinformation to identify available parking spaces, as explained infurther detail below. In some examples, the section manager 112 mayreceive other data from the parking facility such as data from camerasor other sensors located in the parking facility. This data may also betemporarily stored in the database 310 and may be utilized by theparking space recognition module 312. Vehicles may also transmitrequests for parking assistance to the section manager 112 along withassociated information and this information may be temporarily stored inthe database 310.

The database 310 may also permanently store a detailed map of theassociated parking facility. The map may include locations of allparking spaces within the parking facility, such as the map 210 shown inFIG. 2B. The database 310 may also store information about each of theparking spaces in the associated parking facility, such as the size ofthe parking spaces and parking rates. This information may beperiodically updated as parking rates and other information about theparking spaces change.

Referring still to FIG. 3, the parking space recognition module 312 mayrecognize available parking spaces within the parking facility usingtechniques described herein. As one or more vehicles drive through aparking facility, the vehicles may have sensors collecting data aboutthe driving environment. The sensors on vehicles may include, but arenot limited to, LiDAR sensors, RADAR sensors, optical sensors (e.g.,cameras), laser sensors, proximity sensors, location sensors (e.g., GPSmodules), and the like.

As the sensor data is collected by vehicles in the parking facility, thesensor data may be transmitted to the section manager 112 associatedwith the parking facility and the parking space recognition module 312may analyze this sensor data to identify available parking spaces. Forexample, as a vehicle is approaching an available parking space, anexternal camera on the vehicle may capture an image showing that theparking space is vacant. In another example, as a vehicle passes anoccupied parking space, a proximity sensor may detect the vehicle in theparking space, whereas when the vehicle passes an empty parking space,the proximity sensor may not detect a vehicle, indicating that the spaceis available.

In addition to sensor data, vehicles in the parking facility may alsotransmit their position to the section manager 112 (e.g., based on GPSdata received by the vehicles). The parking space recognition module 312may use the received sensor data in conjunction with the position dataand a map of the parking facility to identify available parking spacesin the parking facility. The more vehicles that are driving in theparking facility and transmitting sensor data to the section manager112, the more comprehensive and accurate the parking space recognitionmodule 312 may be in identifying available parking spaces. In someexamples, the section manager 112 may also receive data from othersensors or cameras in the parking facility (e.g., images from securitycameras or designated parking space monitoring sensors). In theseexamples, the parking space recognition module 312 may utilize this dataeither alone or in conjunction with sensor data received from vehiclesto identify available parking spaces in the parking facility.

As additional data is received by the section manager 112, the parkingspace recognition module 312 may continually update the locations ofavailable parking spaces within the parking facility and may store thisinformation in the database 310. As explained above, the data in thesection manager 112 may be updated frequently (e.g., every few seconds)in order to maintain an accurate and timely record of available parkingspaces in the parking facility.

In addition to maintaining a record of the locations of availableparking spaces in an associated parking facility, the section manager112 may also receive requests to provide parking assistance to vehiclesat or approaching the parking facility. The section manager 112 mayprovide parking assistance using the techniques described herein.

The travel time estimation module 314 may estimate the travel time for avehicle requesting parking assistance (e.g., a requesting vehicle) toarrive at an available parking space. When the section manager 112receives a request for parking assistance from a requesting vehicle, thesection manager 112 also receives a location of the requesting vehicle.Thus, the travel time estimation module 314 may estimate the time itwill take the requesting vehicle to arrive at an available parking spacebased on the location of the requesting vehicle, the location of theparking space, and the map of the parking facility. In some examples,the travel time estimation module 314 may estimate the travel time basedon the distance between the requesting vehicle and the available parkingspace. In other examples, the route guidance module 322 may determine anoptimal route between the location of the requesting vehicle and theparking space based on the map of the parking facility (an example routebetween a vehicle and an available parking space is shown in FIG. 13).The travel time estimation module 314 may then estimate the travel timebased on the distance of the determined route.

In some examples, the travel me estimation module 314 may determine anestimated travel tune between the requesting vehicle and each availableparking space in the parking facility. In other examples, the traveltime estimation module 314 may determine an estimated travel timebetween the requesting vehicle and only some of the available parkingspaces in the parking facility (e.g., in a multi-story parking garage,the travel time estimation module 314 may only consider the availableparking spaces on the same floor as the vehicle).

Once the travel time estimation module 314 determines estimated traveltunes to a number of available parking spaces, the section manager 112may determine which available parking space is closest (e.g., indistance or travel time) to the requesting vehicle. However, it ispossible that even though a parking space is available at the time therequesting vehicle requests parking assistance, the parking space may nolonger be available by the time the requesting vehicle arrives at thespace. Moreover, if the section manager 112 guides the requestingvehicle to a parking space that is no longer available by the time therequesting vehicle arrives, the requesting vehicle will have to findanother parking space and the parking assistance will have failed.Accordingly, it may be desirable for the section manager 112 not tosimply guide the requesting vehicle to the closest parking space.Instead, the section manager 112 may predict the likelihood thatavailable parking spaces will still be available when the requestingvehicle arrives, as described below.

The historical usage data acquisition module 316 may acquire historicalusage data for the parking facility and the parking spaces therein. Thismay include data regarding which parking spaces in the parking facilitywere occupied and which parking spaces were available (e.g., parkingoccupancy data) at various times. It may include parking occupancy datafor different clays of the week or different times of day. It mayinclude parking occupancy data for holidays or other special occasions.It may include data correlating the availability of different parkingspaces (e.g., when a first parking space tends to be available, a secondparking space also tends to be available). The historical usage data mayalso include variations in parking availability over time. For example,certain configurations of available parking spaces at one time may tendto result in certain other configurations of available parking spaces ashort time later. In some examples, the historical usage dataacquisition module 316 may acquire historical usage data that is storedin the database 310. In other examples, the historical usage dataacquisition module 316 may acquire historical usage data from anotherserver or computing device associated with the parking facility. As thishistorical usage data is acquired, it may then be stored in the database310.

The parking availability probability determination module 318 maydetermine a probability that an available parking space will still beavailable at a time when the requesting vehicle arrives at the parkingspace. This probability determination may be based on the estimatedtravel time to the available parking space determined by the travel timeestimation module 314, and the historical usage data acquired by thehistorical usage data acquisition module 316.

In the illustrated example, the parking availability probabilitydetermination module 318 uses a Markov model to predict a probabilitythat a parking space will be available at a time in the future. TheMarkov model used by the parking availability probability determinationmodule 318 may comprise a Markov chain that describes a series of statesand a probability of transitioning from any given state at a first timet to any other state at a second time t+1 (e.g., five seconds later).Each state of the Markov chain may comprise occupancy data of theparking facility (e.g., which parking spaces of the facility areoccupied and which parking spaces are available).

The parking availability probability determination module 318 may buildthe Markov chain based on the historical data acquired by the historicalusage data acquisition module 316 and may store the parameters of theMarkov chain in the database 310. As additional data is collected by thehistorical usage data acquisition module 316, the parking availabilityprobability determination module may update the parameters of the Markovchain stored in the database 310.

Once the Markov chain is assembled, the parking availability probabilitydetermination module 318 may input the current state of the parkingfacility (e.g., which parking spaces are available) into the Markovmodel and may propagate the Markov chain forward in time a durationequal to the estimated travel time for the requesting vehicle to arriveat an available parking space. The resulting state of the Markov modelwill provide a probability that a parking space will be available whenthe requesting vehicle arrives at the parking space.

The parking availability probability determination module 318 may usethe Markov model to estimate the probability that each of the availableparking spaces will be available when the requesting vehicle wouldarrive at each parking space based on the estimated travel time to eachparking space. In other examples, methodologies other than a Markovmodel may be used by the parking availability probability determinationmodule 318 to determine probabilities of parking spaces remainingavailable at a time when a requesting vehicle would arrive.

The parking space selection module 320 selects an available parkingspace to recommend to the requesting vehicle. The parking spaceselection module 320 may use a variety of factors to determine whichavailable parking space to recommend to the requesting vehicle. Thesefactors may include the estimated travel time to the parking space andthe probability that the parking space will still be available when therequesting vehicle arrives at the space, among other factors.

In one example, the parking space selection module 320 may recommend theavailable parking space that has the shortest estimated travel time forthe requesting vehicle to arrive. In another example, the parking spaceselection module 320 may recommend the available parking space that hasthe highest probability of remaining available when the requestingvehicle arrives. In another example, the parking space selection module320 may recommend the available parking space that has the shortestestimated travel time for the requesting vehicle to arrive amongavailable parking that have a probability of remaining available above apredetermined threshold.

In some examples, the requesting vehicle may transmit a finaldestination to the section manager 112 (e.g., the destination that thedriver of the vehicle will walk to after parking) and the parking spaceselection module 320 may select an available parking space based on thedistance between the available parking and the received finaldestination (e.g., selecting a parking space that is close to the finaldestination). In some examples, the requesting vehicle may transmit oneor more preferences to the section manager 112 (e.g., the size of therequesting vehicle, the maximum parking fee the driver is willing topay, etc.). The parking space selection module 320 may then select aparking space based on these received preferences. For example, theparking space selection module 320 may avoid recommending a parkingspace that would be difficult for the requesting vehicle to park inbased on the size of the vehicle and the size of the parking space. Inanother example, the parking space selection module 320 may avoidrecommending a parking space that has a parking fee higher than what thedriver of the requesting vehicle is willing to pay.

The route guidance module 322 may determine an optimal route between thelocation of the requesting vehicle and the location of the parking spaceselected by the parking space selection module 320. The route guidancemodule 322 may determine the optimal route based on the map of theparking facility stored in the database 310. FIG. 13 shows an exemplaryroute between a vehicle and an available parking space in a parkingfacility. In some examples where a parking facility has multipleentrances, the route guidance module 322 may recommend the entrance tothe parking facility that minimizes the expected travel time to theselected parking space. After the route guidance module 322 determinesthe optimal route, the section manager 112 may transmit the route to therequesting vehicle. The requesting vehicle may then follow thedetermined route to arrive and park at the available parking space.

The section manager 112 may also periodically transmit the number ofavailable parking spaces within the parking facility to the localitymanager 122. In one example, the section manager 112 may transmit thenumber of available parking spaces to the locality manager 122 whenevera designated time has elapsed since the last transmission. In anotherexample, the section manager 112 may transmit the number of availableparking spaces whenever the number of available parking spaces haschanged more than a threshold amount since the last transmission. Inanother example, the section manager 112 may transmit the number ofavailable parking spaces whenever the number of available parking spacesbecomes greater than a predetermined threshold or becomes less than apredetermined threshold. The transmitted number of available parkingspaces within the parking facility may be received by the localitymanager 122 and utilized as described below in connection with FIG. 4.

Referring now to FIG. 4, the locality manager 122 is described. Asexplained above, the locality manager 122 may manage parking assistancefor a locality containing one or more parking facilities managed bysection managers 112. In one example, the locality manager 122 may be anedge server or other server or computing device located in or adjacentto the associated locality. In other examples, the locality manager 122may be a cloud server or other distributed computing device.

The locality manager 122 comprises one or more processors 402, one ormore memory modules 404, network interface hardware 406, and acommunication path 408. The one or more processors 402 may be acontroller, an integrated circuit, a microchip, a computer, or any othercomputing device. The one or more memory modules 404 may comprise RAM,ROM, flash memories, hard drives, or any device capable of storingmachine readable and executable instructions such that the machinereadable and executable instructions can be accessed by the one or moreprocessors 402. The communication path 408 provides signalinterconnectivity between various modules of the locality manager 122.

The network interface hardware 406 can be communicatively coupled to thecommunication path 408 and can be any device capable of transmittingand/or receiving data via a network. Accordingly, the network interfacehardware 406 can include a communication transceiver for sending and/orreceiving any wired or wireless communication. For example, the networkinterface hardware 406 may include an antenna, a modem, LAN port, Wi-Ficard, WiMax card, mobile communications hardware, near-fieldcommunication hardware, satellite communication hardware and/or anywired or wireless hardware for communicating with other networks and/ordevices. In one embodiment, the network interface hardware 406 includeshardware configured to operate in accordance with the Bluetooth®wireless communication protocol. The network interface hardware 406 ofthe locality manager 122 may receive data from the one or more sectionmanagers 112 in the locality managed by the locality manager 122 and maytransmit data to the city manager 132 that manages the region in whichthe locality manager 122 resides. In addition, the network interfacehardware 406 may receive requests for parking assistance from vehicleswithin the associated locality.

The one or more memory modules 404 include a database 410, a facilityparking availability determination module 412, a travel time estimationmodule 414, a historical facility usage data acquisition module 416, aparking facility availability estimation module 418, a parking facilityselection module 420, and a route guidance module 422. Each of thedatabase 410, the facility parking availability determination module412, the travel time estimation module 414, the historical facilityusage data acquisition module 416, the parking facility availabilityestimation module 418, the parking facility selection module 420, andthe route guidance module 422 may be a program module in the form ofoperating systems, application program modules, and other programmodules stored in one or more memory modules 404. In some embodiments,the program module may be stored in a remote storage device that maycommunicate with the locality manager 122. Such a program module mayinclude, but is not limited to, routines, subroutines, programs,Objects, components, data structures and the like for performingspecific tasks or executing specific data types as will be describedbelow.

The database 410 may temporarily store data received from one or moresection managers 112 in the locality. This data may include parkingavailability data regarding the parking facilities associated with thesection managers 112 (e.g., the number of available parking spaces ineach such parking facility). The facility parking availabilitydetermination module 412 may use this information to determine parkingavailability in the locality associated with the locality manager 122,as explained in further detail below. The locality manager 122 may alsoreceive requests for parking assistance from vehicles in the localityalong with associated information and this information may be stored inthe database 410 as well.

The database 410 may also permanently store a map of the associatedlocality. The map may include locations of all of the parking facilitieswithin the locality, such as the map 220 shown in FIG. 2C. The database410 may also store information about each of the parking facilities inthe locality, such as parking rates. This information may beperiodically updated as parking rates and other information about theparking facilities change.

Referring still to FIG. 4, the facility parking availabilitydetermination module 412 may determine the number of parking spaces thatare available at each parking facility within the locality. The facilityparking availability determination module 412 may make thisdetermination based on the parking availability data received from thesection managers 112 that manage the parking facilities within thelocality. This parking availability data may be periodically updated asadditional data is received from the section managers 112. However, thedata may be updated less frequently than the section managers 112 updateparking availability maps of the parking facilities. This is because thetotal number of parking spaces available in a parking facility is lesssensitive to minor variations than the availability of specific parkingspaces in the facility. Thus, while the section managers 112 may updateparking availability maps every few seconds, the locality manager 122may only update parking availability numbers every few minutes, forexample. The frequency with which the section managers 112 transmitparking availability data to the locality manager 122 may be adjustedaccordingly.

In addition to maintaining a record of the number of available parkingspaces in each of the parking facilities in the locality, the localitymanager 122 may also receive requests to provide parking assistance tovehicles within or approaching the locality. The locality manager 122may provide parking assistance using the techniques described herein.

The travel time estimation module 414 may estimate the travel time for avehicle requesting parking assistance (e.g., a requesting vehicle) toarrive at a parking facility within the locality. When the localitymanager 122 receives a request for parking assistance from a requestingvehicle, the locality manager 122 also receives a location of therequesting vehicle. Thus, the travel time estimation module 414 mayestimate the time it will take the requesting vehicle to arrive at aparking facility based on the location of the requesting vehicle, thelocation of the parking facility, and the map of the locality. In someexamples, the travel time estimation module 414 may estimate the traveltime based on the distance between the requesting vehicle and theparking facility. In other examples, the route guidance module 422 maydetermine an optimal route between the location of the requestingvehicle and the parking facility based on the map of the locality. Thetravel time estimation module 414 may then estimate the travel timebased on the distance of the determined route.

In some examples, the travel time estimation module 414 may determine anestimated travel time between the requesting vehicle and each parkingfacility in the locality. In other examples, the travel time estimationmodule 414 may determine an estimated travel time between the requestingvehicle and only some of the parking facilities in the locality (e.g.,only the parking facilities within a threshold distance from therequesting vehicle, or only the parking facilities that meet certainpreferences received from the requesting vehicle).

Once the travel time estimation module 414 determines estimated traveltimes to a number of parking facilities in the locality, the localitymanager 122 may determine which parking facility is closest (e.g., indistance or (ravel time) to the requesting vehicle. However, it ispossible that even if a parking facility has available parking spaces atthe time the requesting vehicle requests parking assistance, the parkingfacility may no longer have any available parking spaces by the time therequesting vehicle arrives at the parking facility. Moreover, if thelocality manager 122 guides the requesting vehicle to a parking facilitythat does not have any available parking spaces when the requestingvehicle arrives, the requesting vehicle will have to park at anotherfacility and the parking assistance will have failed. Accordingly, thelocality manager 122 may predict the number of parking spaces that willbe available in a parking facility when the requesting vehicle arrives,as described below, rather than simply recommending the closest parkingfacility with available parking.

The historical facility usage data acquisition module 416 may acquirehistorical usage data for the parking facilities within the locality.This may include the number of available parking spaces in each parkingfacility at different times in the past. The historical usage data mayalso include variations in the number of available parking spaces ineach parking facility over time. In some examples, the historicalfacility usage data acquisition module 416 may acquire historical usagedata that is stored in the database 410. In other examples, thehistorical facility usage data acquisition module 416 may acquirehistorical usage data from another server or computing device associatedwith the parking facilities in the locality. Such acquired data may thenbe stored in the database 410.

The parking facility availability estimation module 418 may estimate thenumber of parking spaces that will be available in a parking facility ata time when the requesting vehicle arrives at the parking facility. Thisestimation may be based on the estimated travel time to the parkingfacility determined by the travel time estimation module 414, and thehistorical usage data acquired by the historical facility usage dataacquisition module 416.

In the illustrated example, the parking facility availability estimationmodule 418 uses a Markov model to estimate the number of parking spacesthat will be available in a parking facility at a time in the future.The Markov model used by the parking facility availability estimationmodule 418 may comprise a Markov chain that describes a series of statesand a probability of transitioning from any given state at a first timet to any other state at a second time t+1 (e.g., five minutes later).Each state of the Markov chain may comprise a number of parking spacesavailable in a parking facility. The states of the Markov chain may alsocomprise information about the time of clay or the day of the week. Theparking facility availability estimation module 418 may build the Markovchain based on the historical data acquired by the historical facilityusage data acquisition module 416 and may store the parameters of theMarkov chain in the database 410. Each parking facility in the localitymay be associated with a different Markov model. In other examples, theparking facility availability estimation module 418 may utilizemethodologies other than a Markov model.

Once the Markov chain is assembled, the parking facility availabilityestimation module 418 may input the current number of parking spacesavailable in each parking facility in the locality into the Markov modeland may propagate the Markov chain forward in time a duration equal tothe estimated travel time for the requesting vehicle to arrive at eachof the parking facilities. The resulting state of the Markov model willprovide an estimated number of parking spaces available in each parkingfacility in the locality when the requesting vehicle would at eachfacility.

The parking facility selection module 420 may select a parking facilityto recommend to the requesting vehicle to park. The parking facilityselection module 420 may use a variety of factors to determine whichlocality to recommend to the requesting vehicle. These factors mayinclude the estimated travel time to the parking facility and theestimated number of parking spaces that will he available when therequesting vehicle arrives at the parking facility, among other factors.

In one example, the parking facility selection module 420 may recommendthe parking facility that has the shortest estimated travel time for therequesting vehicle to arrive. In another example, the parking facilityselection module 420 may recommend the parking facility that has themost estimated number of available parking spaces when the requestingvehicle arrives. In another example, the parking facility selectionmodule 420 may recommend the parking facility that has the shortestestimated travel time for the requesting vehicle to arrive among parkingfacilities that have an estimated number of available parking spacesabove a predetermined threshold. in some examples, the parking facilityselection module 420 may select a parking facility based on the distancebetween the parking facility and the final destination of the driver ofthe requesting vehicle. In some examples, the parking facility selectionmodule 420 may select the parking facility based on preferences receivedfrom the requesting vehicle, such as parking rates.

The route guidance module 422 may determine an optimal route between thelocation of the requesting vehicle and the location of the parkingfacility selected by the parking facility selection module 420. Theroute guidance module 422 may determine the optimal route based on themap of the locality stored in the database 410. After the route guidancemodule 422 determines the optimal route, the locality manager 122 maytransmit the route to the requesting vehicle. The requesting vehicle maythen follow the determined route to arrive at the selected parkingfacility. If the estimated parking availability of the selected parkingfacility changes while the vehicle is in transit to the selected parkingfacility, the locality manager 122 may select a new parking facility andmay transmit, to the requesting vehicle, a revised route to the newlyselected parking facility. Once the requesting vehicle arrives at theselected parking facility, the requesting vehicle may transmit a requestto the section manager 112 associated with the parking facility forassistance in finding a particular parking space in the parkingfacility.

The locality manager 122 may also periodically transmit the aggregatenumber of available parking spaces in all the parking facilities withinthe locality to the city manager 132. In one example, the localitymanager 122 may transmit the number of available parking spaces in thelocality to the city manager 132 when a designated time has elapsedsince the last such transmission. In another example, the localitymanager 122 may transmit the number of available parking spaces to thecity manager 132 when the number of available parking spaces has changedby more than a threshold amount since the last transmission. In anotherexample, the locality manager 122 may transmit the number of availableparking spaces to the city manager 132 when the number of availableparking spaces becomes greater than a threshold or lower than athreshold. The city manager 132 may receive the number of availableparking spaces in the locality and utilize the received data asdescribed below, in connection with FIG. 5.

Referring now to FIG. 5, the city manager 132 is described. As explainedabove, the city manager 132 may manage parking assistance for a regioncontaining one or more locality managers 122. The city manager 132 maybe an edge server or other server or computing device located in oradjacent to the associated region. In some examples, the city manager132 may be a cloud server or other distributed computing device.

The city manager 132 comprises one or more processors 502, one or morememory modules 504, network interface hardware 506, and a communicationpath 508. The one or more processors 502 may be a controller, anintegrated circuit, a microchip, a computer, or any other computingdevice. The one or more memory modules 504 may comprise RAM, ROM, flashmemories, hard drives, or any device capable of storing machine readableand executable instructions such that the machine readable andexecutable instructions can be accessed by the one or more processors502. The communication path 508 provides signal interconnectivitybetween various modules of the city manager 132.

The network interface hardware 506 can be communicatively coupled to thecommunication path 508 and can be any device capable of transmittingand/or receiving data via a network. Accordingly, the network interfacehardware 506 can include a communication transceiver for sending and/orreceiving any wired or wireless communication. For example, the networkinterface hardware 506 may include an antenna, a modem, LAN port, Wi-Ficard, WiMax card, mobile communications hardware, near-fieldcommunication hardware, satellite communication hardware and/or anywired or wireless hardware for communicating with other networks and/ordevices. In one embodiment, the network interface hardware 506 includeshardware configured to operate in accordance with the Bluetooth®wireless communication protocol. The network interface hardware 506 ofthe city manager 132 may receive data from the one or more localitymanagers 122 in the region managed by the city manager 132. In exampleswhere there is a fourth level of managers above the city manager 132,the network interface hardware 506 may transmit data to the fourth levelmanager that manages the geographic area in which the city manager 132resides. In addition, the network interface hardware 506 may receiverequests for parking assistance from vehicles within the associatedregion.

The one or more memory modules 504 include a database 510, a localityparking availability determination module 512, a travel time estimationmodule 514, a historical locality usage data acquisition module 516, aparking locality availability estimation module 518, a parking localityselection module 520, and a route guidance module 522. Each of thedatabase 510, the locality parking availability determination module512, the travel time estimation module 514, the historical localityusage data acquisition module 516, the parking locality availabilityestimation module 518, the parking locality selection module 520, andthe route guidance module 522 may be a program module in the form ofoperating systems, application program modules, and other programmodules stored in one or more memory modules 504. In some embodiments,the program module may be stored in a remote storage device that maycommunicate with the city manager 132. Such a program module mayinclude, but is not limited to, routines, subroutines, programs,objects, components, data structures and the like for performingspecific tasks or executing specific data types as will be describedbelow.

The database 510 may temporarily store data received from one or morelocality managers 122 in the region managed by the city manager 132.This data may include parking availability data regarding the localitiesassociated with the locality managers 122 (e.g., the number of availableparking spaces in each such locality). The locality parking availabilitydetermination module 512 may use this information to determine parkingavailability in the region associated with the city manager 132, asexplained in further detail below. The city manager 132 may also receiverequests for parking assistance from vehicles in the region along withassociated information and this information may be stored in thedatabase 510.

The database 510 may also permanently store a map of the associatedregion. The map may include locations of all of the localities withinthe region, such as the map 230 shown in FIG. 2D. The database 510 mayalso store information about each of the localities in the region, suchas general information about parking in the locality. This informationmay be periodically updated as information changes.

Referring still to FIG. 5, the locality parking availabilitydetermination module 512 may determine the number parking spaces thatare available in each locality within the region. The locality parkingavailability determination module 512 may make this determination basedon the parking availability data received from the locality managers 122that manage the localities within the region. This parking availabilitydata may be periodically updated as additional data is received from thelocality managers 122. However, the data may be updated less frequentlythan the locality managers 122 update parking availability data for theparking facilities in the associated localities. This is because theregion managed by the city manager 132 covers a large geographic areaand errors in the number of parking spaces available in a locality atany given time may be less important n errors in the number of parkingspaces available in a parking facility. Thus, while the localitymanagers 122 may update parking availability data every few minutes, thecity manager 132 may only update parking availability data every hour,for example. The frequency with which the locality managers 122 transmitparking availability data to the city manager 132 may be adjustedaccordingly.

In addition to maintaining a record of the number of available parkingspaces in each locality within the region, the city manager 132 may alsoreceive requests to provide parking assistance to vehicles within orapproaching the region. The city manager 132 may provide parkingassistance using the techniques described herein.

The travel time estimation nodule 514 may estimate the travel time for avehicle requesting parking assistance (e.g., a requesting vehicle) toarrive at a locality within region. When the city manager 132 receives arequest for parking assistance from a requesting vehicle, the citymanager 132 also receives a location of the requesting vehicle. Thus,the travel time estimation module 514 may estimate the time it will takethe requesting vehicle to arrive at a locality based on the location ofthe requesting vehicle, the location of the locality, and the map of theregion. In some examples, the travel time estimation module 514 mayestimate the travel time based on the distance between the requestingvehicle and the locality. In other examples, the route guidance module522 may determine an optimal route between the location of therequesting vehicle and the locality based on the map of the region. Thetravel time estimation module 514 may then estimate the travel timebased on the distance of the determined route.

In some examples, the travel time estimation module 514 may determineestimated travel time between the requesting vehicle and each localitywithin the region. In other examples, the travel time estimation module514 may determine an estimated travel time between the requestingvehicle and only some of the localities within the region (e.g., onlythe localities within a threshold distance from the requesting vehicle).

Once the travel time estimation module 514 determines estimated traveltimes to a number of localities in the region, the city manager 132 maydetermine which parking facility is closest (e.g., in distance or traveltime) to the requesting vehicle. The city manager 132 may also predictthe number of parking spaces that will be available in one or more ofthe localities when the requesting vehicle arrives, as described below.A driver may generally desire to park in a locality that is close totheir final destination so that significant walking to the finaldestination is not required. Thus, it may not be desirable for the citymanager 132 to recommend an alternative locality for the driver to park.However, if parking is significantly easier to find in an alternativelocality, and if there are options to get from the locality to the finaldestination (e.g., public transportation, taxis, ride-share), it may bedesirable for the city manager 132 to recommend an alternative localityfor parking, as described below.

The historical locality usage data acquisition module 516 may acquirehistorical usage data for the localities within the region. This mayinclude the number of available parking spaces in each locality atdifferent times in the past. The historical usage data may also includevariations in the number of available parking spaces in each localityover time. In some examples, the historical locality usage dataacquisition module 516 may acquire historical usage data that is storedin the database 510. In other examples, the historical locality usagedata acquisition module 516 may acquire historical usage data fromanother server or computing device associated with the localities in theregion. In these examples, the acquired historical usage data may thenbe stored in the database 510.

The parking locality availability estimation module 518 may estimate thenumber of parking spaces that will be available in a locality at a timewhen the requesting vehicle arrives at the locality. This estimation maybe based on the estimated travel time to the locality determined by thetravel time estimation module 514 and the historical usage data acquiredby the historical locality usage data acquisition module 516.

In the illustrated example, the parking locality availability estimationmodule 518 uses a Markov model to estimate the number of parking spacesthat will be available in a locality at a time in the future. The Markovmodel used by the parking locality availability estimation module 518may comprise a Markov chain that describes a series of states and aprobability of transitioning from any given state at a first time t toany other state at a second time t±1 (e.g., twenty minutes later). Eachstate of the Markov chain may comprise a number of parking spacesavailable within a locality in the region. The states of the Markovchain may also comprise information about the time of day or the day ofthe week. The parking locality availability estimation module 518 maybuild the Markov chain based on the historical data acquired by thehistorical locality usage data acquisition module 516 and may store theparameters of the Markov chain in the database 510. Each locality in theregion may be associated with a different Markov model. In otherexamples, the parking locality availability estimation module 518 mayuse methodologies other than a Markov model.

Once the Markov chain is assembled, the parking locality availabilityestimation module 518 may input the current number of parking spacesavailable in each locality in the region into the Markov model and maypropagate the Markov chain forward in time a duration equal to theestimated travel time for the requesting vehicle to arrive at each ofthe localities. The resulting state of the Markov model will provide anestimated number of parking spaces available in each locality when therequesting vehicle would arrive at each locality.

The parking locality selection module 520 selects a locality torecommend to the requesting vehicle. The parking locality selectionmodule 520 may use a variety of factors to determine which parkingfacility to recommend to the requesting vehicle. These factors mayinclude the estimated travel time to the locality and the estimatednumber of parking spaces that will be available when the requestingvehicle arrives at the locality, among other factors.

In one example, the parking locality selection module 520 may recommendthe locality that has the shortest estimated travel time for therequesting vehicle to arrive. In another example, the parking localityselection module 520 may recommend the locality that has the mostestimated number of available parking spaces when the requesting vehiclearrives. In another example, the parking locality selection module 520may recommend the locality that has the shortest estimated travel timefor the requesting vehicle to arrive among localities that have anestimated number of available parking spaces above a predeterminedthreshold. In some examples, the parking locality selection module 520may select a locality based on the distance between the locality and thefinal destination of the driver of the requesting vehicle. In someexamples, the parking locality selection module 520 may select thelocality based on preferences received from the requesting vehicle, suchas the availability of public transportation within the locality.

The route guidance module 522 may determine an optimal route between thelocation of the requesting vehicle and the location of the localityselected by the parking locality selection module 520. The routeguidance module 522 may determine the optimal route based on the map ofthe region stored in the database 510. After the route guidance module522 determines the optimal route, the city manager 132 may transmit theroute to the requesting vehicle. The requesting vehicle may then followthe determined route to arrive at the selected locality. If theestimated parking availability of the selected locality changes whilethe vehicle is in transit to the selected locality, the city manager 132may select a new locality and may transmit, to the requesting vehicle, arevised route to the newly selected locality. Once the requestingvehicle arrives at the selected locality, the requesting vehicle maytransmit a request to the locality manager 122 associated with thelocality for assistance in finding a parking facility within thelocality.

By utilizing the hierarchical structure of level managers describedabove, the operation of the system 100 may be balanced across thevarious manager components. The load on any manager component isgenerally proportional to the frequency of refreshing parkingavailability information multiplied, by the number of vehicles orlower-level managers from which it receives data. Thus, since thesection managers 112 manage a small geographic area with a high refreshrate, the locality managers 122 manage a larger area with a lowerrefresh rate, and the city managers 132 manage the largest area with thelowest refresh rate, the load on each manager is relatively balanced.This helps to improve the scalability of the system 100.

FIG. 6 depicts a flowchart for a method that may be implemented by thesection manager 112 to identify available parking spaces in the parkingfacility managed by the section manager 112. At step 600, the sectionmanager 112 receives sensor data from one or more vehicles in theparking facility via the network interface hardware 306. The sectionmanager 112 may store the received sensor data in the database 310.

At step 602, the section manager 112 receives position data from the oneor more vehicles in the parking facility via the network interfacehardware 306. The position data of the vehicles corresponds to thepositions of each of the one or more vehicles when the sensor data iscollected. The section manager 112 may store the received position datain the database 310.

At step 604, the parking space recognition module 312 identifiesavailable parking spaces in the parking facility based on the sensordata and position data received from the vehicles in the parkingfacility and a map of the parking facility stored in the database 310.At step 606, the section manager 112 transmits, via the networkinterface hardware 306, the total number of available parking spaces inthe parking facility to the locality manager 122 that manages thelocality in which the parking facility resides.

FIG. 7 depicts a flowchart for a method that may be implemented by thelocality manager 122 to determine the number of parking spaces availablein each parking facility in the locality managed by the locality manager122. At step 700, the locality manager 122 receives, via the networkinterface hardware 406, parking availability data from each of thesection managers 112 that manage parking facilities in the locality. Theparking availability data may comprise the number of available parkingspaces in each parking facility in the locality. The parkingavailability data may be stored in the database 410.

At step 702, the facility parking availability determination module 412determines the number of available parking spaces in each parkingfacility in the locality based on the parking availability data receivedfrom the section managers 112. At step 704, the locality manager 122transmits, via the network interface hardware 406, the total number ofavailable parking spaces in all of the parking facilities in thelocality.

FIG. 8 depicts a flowchart for a method that may be implemented by thecity manager 132 to determine the number of parking spaces available ineach locality in the region managed by the city manager 132. At step800, the city manager 132 receives, via the network interface hardware506, parking availability data from each locality within the regionmanaged by the city manager 132. The parking availability data maycomprise the number of available parking spaces within each locality inthe region and may be stored in the database 510. At step 802, thelocality parking availability determination module 512 determines thenumber of available parking spaces in each locality in the region basedon the parking availability data received from the locality managers122.

FIG. 9 depicts a flowchart for a method that may be implemented by thesection manager 112 to provide parking assistance to a vehicle. At step900, the section manager 112 receives a request for parking assistancefrom a vehicle along with the position of the vehicle.

At step 902, the parking space recognition module 312 determines thelocations of available parking spaces in the parking facility. Theparking space recognition module 312 may determine the locations ofavailable parking spaces using the method discussed above in connectionwith FIG. 6.

At step 904, the travel time estimation module 314 determines estimatedtravel times to each of the available parking spaces in the parkingfacility identified by the parking space recognition module 312. At step906, the historical usage data acquisition module 316 acquireshistorical usage data for the parking facility and the parking spacestherein. At step 908, the parking availability probability determinationmodule 318 determines the probability that each of the available parkingspaces identified by the parking space recognition module 312 will beavailable at a time that the vehicle would arrive at each of the parkingspaces.

FIG. 10 depicts a flowchart for another method that may be implementedby the section manager 112 to provide parking assistance to a vehicle.At step 1000, the section manager 112 receives a request for parkingassistance from a vehicle. The request for parking assistance includes aposition of the vehicle. The request for parking assistance may alsoinclude one or more parking-related preferences.

At step 1002, the parking space recognition module 312 identifies one ormore available parking spaces in the parking facility. The parking spacerecognition module 312 may identify available parking spaces using themethod described above in connection with FIG. 6.

At step 1004, the travel time estimation module 314 determines anestimated travel time for the vehicle to reach each of the availableparking spaces identified by the parking space recognition module 312.The travel time estimation module 314 may determine the estimated travelbased on the location of the vehicle, the location of each of theavailable parking spaces, and a map of the parking facility stored inthe database 310.

At step 1006, the historical usage data acquisition module 316 acquireshistorical usage data for the parking facility. Then, at step 1008, theparking availability probability determination module 318 determines theprobability that each of the available parking spaces identified by theparking space recognition module 312 will be available when the vehiclearrives at the parking spaces. The parking availability probabilitydetermination module 318 may determine the probabilities based on theavailable parking spaces and the historical usage data acquired by thehistorical usage data acquisition module 316.

At step 1010, the parking space selection module 320 selects anavailable parking space to recommend for the vehicle to park. Theparking space selection module 320 may select an available parking spacebased on the estimated arrival time of the vehicle, the probability ofthe parking space being available when the vehicle arrives, as well asany preferences received from the vehicle and corresponding features ofthe available parking spaces.

At step 1012 the route guidance module 322 determines the optimal routefor the vehicle to travel to arrive at the selected parking space. Theroute guidance module 322 may determine the optimal route based on thelocation of the vehicle, the location of the selected parking space, andthe map of the parking facility. Then, at step 1014, the section manager112 transmits the determined route to the vehicle.

FIG. 11 depicts a flowchart for a method that may be implemented by thelocality manager 122 to provide parking assistance to a vehicle. At step1100, the locality manager 122 receives a request from a vehicle forparking assistance. The request for parking assistance includes alocation of the vehicle. The request for parking assistance may alsoinclude one or more parking-related preferences.

At step 1102, the facility parking availability determination module 412determines the number of parking spaces available in each of the parkingfacilities in the locality managed by the locality manager 122. Thefacility parking availability determination module 412 may determine thenumber of parking spaces available based on parking availability datareceived from the section managers 112 that manage the parkingfacilities in the locality.

At step 1104, the travel time estimation module 414 estimates the traveltime for the vehicle to arrive at each of the parking facilities in thelocality. The travel time estimation module 414 may estimate the traveltimes based on the location of the vehicle, the locations of the parkingfacilities, and a map of the locality stored in the database 410.

At step 1106, the historical facility usage data acquisition module 416acquires historical usage data for the parking facilities in thelocality. Then, at step 1108, the parking facility availabilityestimation module 418 determines an estimated number of parking spacesthat will be available in each parking facility in the locality when thevehicle would arrive at each parking facility. The parking facilityavailability estimation module 418 may determine this estimated numberbased on the number of available parking spaces in each parking facilityand the historical usage data acquired by the historical facility usagedata acquisition module 416.

At step 1110, the parking facility selection module 420 selects aparking facility to recommend for the vehicle to park at. The parkingfacility selection module 420 may select a parking facility based on theestimated travel time to each parking facility, the estimated number ofparking spaces that will be available at each parking facility when thevehicle arrives, as well as any parking-related preferences receivedfrom e vehicle and associated features of the parking facilities.

At step 1112, the route guidance module 422 determines the optimal routefor the vehicle to travel to arrive at the selected parking facility.The route guidance module 422 may determine the optimal route based onthe location of the vehicle, the location of the selected parkingfacility, and the map of the locality. Then, at step 1114, the localitymanager 122 transmits the determined route to the vehicle.

FIG. 12 depicts a flowchart for a method that may be implemented by thecity manager 132 to provide parking assistance to a vehicle. At step1200, the city manager 132 receives a request from a vehicle for parkingassistance. The request for parking assistance includes a location ofthe vehicle. The request for parking assistance may also include one ormore parking-related preferences.

At step 1202, the locality parking availability determination module 512determines the number of parking spaces available within each localityin the region managed by the city manager 132. The locality parkingavailability determination module 512 may determine the number ofparking spaces available based on parking availability data receivedfrom the locality managers 122 that manage the localities in the region.

At step 1204, the travel time estimation module 514 estimates the traveltime for the vehicle to arrive at each of the parking facilities in thelocality. The travel time estimation module 514 may estimate the traveltimes based on the location of the vehicle, the locations of the parkingfacilities, and a map of the region stored in the database 510.

At step 1206, the historical locality usage data acquisition module 516acquires historical usage data for the localities in the region. Then,at step 1208, the parking locality availability estimation module 518determines an estimated number of parking spaces that will be availablein each locality in the region when the vehicle would arrive at eachlocality. The parking locality availability estimation module 518 maydetermine this estimated number based on the number of available parkingspaces in each locality and the historical usage data acquired by thehistorical locality usage data acquisition module 516.

At step 1210, the parking locality selection module 520 selects alocality to recommend for the vehicle to park in. The parking localityselection module 520 may select a locality based on the estimated traveltime to each locality, the estimated number of parking spaces that willbe available within each locality when the vehicle arrives, as well asany parking-related preferences received from the vehicle and associatedfeatures of the localities.

At step 1212, the route guidance module 522 determines the optimal routefor the vehicle to travel to arrive at the selected locality. The routeguidance module 522 may determine the optimal route based on thelocation of the vehicle, the location of the selected locality, and themap of the region. Then, at step 1214, the city manager 132 transmitsthe determined route to the vehicle.

It should be understood that embodiments described herein are directedto a hierarchical system for providing parking assistance to vehicles.The system includes multiple levels of managers in a hierarchicalrelationship. Section managers each manage a single parking facility andreceive sensor data from vehicles in the parking facility. The sectionmanagers use the received vehicle sensor data to track available parkingspaces within the parking facility. A section manager may receive arequest for parking assistance from a vehicle and may guide the vehicleto an available parking space in the parking facility managed by thesection manager.

Locality managers operate at a higher hierarchical level than thesection managers and each manage a locality comprising one or moreparking facilities, each managed by a section manager. The localitymanagers receive parking availability data from the section managers anduse the received parking availability data to track the number ofparking spaces available in each parking facility in the locality. Alocality manager may receive a request for parking assistance from avehicle and may guide the vehicle to a less congested parking facilityin the locality managed by the locality manager.

City managers operate at a higher hierarchical level than the localitymanagers and each manage a region comprising one or more localities,each managed by a locality manager. The city managers receive parkingavailability data from the locality managers and use the receivedparking availability data to track the number of parking spacesavailable in each locality in the region. A city manager may receive arequest for parking assistance from a vehicle and may guide the vehicleto a less congested locality in the region managed by the city manager.

It is noted that the terms substantially and “about” may be utilizedherein to represent the inherent degree of uncertainty that may beattributed to any quantitative comparison, value, measurement, or otherrepresentation. These terms are also utilized herein to represent thedegree by which a quantitative representation may vary from a statedreference without resulting in a change in the basic function of thesubject matter at issue.

While particular embodiments have been illustrated and described herein,it should be understood that various other changes and modifications maybe made without departing from the spirit and scope of the claimedsubject matter. Moreover, although various aspects of the claimedsubject matter have been described herein, such aspects need not beutilized in combination. It is therefore intended that the appendedclaims cover all such changes and modifications that are within thescope of the claimed subject matter.

1. (canceled)
 2. (canceled)
 3. (canceled)
 4. (canceled)
 5. (canceled) 6.(canceled)
 7. (canceled)
 8. (canceled)
 9. (canceled)
 10. A system formanaging parking facilities comprising: a plurality of first levelmanagers each managing a parking facility; and at least one second levelmanager being in a higher hierarchical level than the plurality of firstlevel managers and managing a locality, wherein: each of the pluralityof first level managers is configured to: receive sensor data from oneor more vehicles within the parking facility managed by the first levelmanager and position data corresponding to a position of each of the oneor more vehicles within the parking facility, the parking facilityhaving a plurality of parking spaces; and the at least one second levelmanager is configured to: receive facility parking availability datafrom one or more of the plurality of first level managers in thelocality managed by the at least one second level manager, wherein afirst frequency of the first level managers receiving the sensor datafrom the one or more vehicles is higher than a second frequency of theat least one second level manager receiving the facility parkingavailability data from the plurality of first level managers.
 11. Thesystem of claim 10, wherein each of the plurality of first levelmanagers is configured to: identify one or more available parking spacesfrom the plurality of parking spaces within the parking facility basedat least in part on the sensor data and the position data received fromthe one or more vehicles; determine facility parking availability datacomprising a number of available parking spaces within the parkingfacility based at least in part on the sensor data collected from theone or more vehicles and a map associated with the parking facility; andtransmit the facility parking availability data to one of the at leastone second level manager, and the at least one second level manager isconfigured to: determine a number of available parking spaces at eachparking facility in the locality based at least in part on the facilityparking availability data.
 12. The system of claim 10, wherein each ofthe plurality of first level managers is further configured to: receive,from a requesting vehicle, a request to locate an available parkingspace within the parking facility managed by the first level manager;receive, from the requesting vehicle, a requesting positioncorresponding to a position of the requesting vehicle; obtain historicalusage data for the one or more available parking spaces within theparking facility managed by the first level manager; determine anestimated travel time for the requesting vehicle to arrive at each ofthe available parking spaces based at least in part on the requestingposition; and for each of the available parking spaces, determine aprobability that the parking space will be available when the requestingvehicle arrives at the parking space based at least in part on theestimated travel time and the historical usage data.
 13. The system ofclaim 12, wherein each of the plurality of first level managers isfurther configured to: select one of the available parking spaces as aselected parking space based at least in part on the probability thatthe selected parking space will be available when the requesting vehiclearrives at the selected parking space; and transmit a location of theselected parking space to the requesting vehicle.
 14. The system ofclaim 13, wherein each of the plurality of first level managers isfurther configured to: determine an optimum travel route between therequesting vehicle and the selected parking space based at least in parton the requesting position, the location of the selected parking space,and a map associated with the parking facility; and transmit the optimumtravel route to the requesting vehicle.
 15. The system of claim 10,wherein the at least one second level manager is further configured to:receive a request to locate an available parking space within thelocality managed by the second level manager from a requesting vehicle;receive a requesting position from the requesting vehicle correspondingto a position of the requesting vehicle; obtain historical facilityusage data for the parking facilities managed by the first levelmanagers in the locality managed by the second level manager; determinean estimated travel time for the requesting vehicle to arrive at each ofthe parking facilities based at least in part on the requestingposition; and for each of the parking facilities, estimate a number ofparking spaces that will be available at the parking facility when therequesting vehicle arrives at the parking facility based at least inpart on the estimated travel time and the historical facility usagedata.
 16. The system of claim 15, wherein the at least one second levelmanager is further configured to: select one of the parking facilitiesas a selected parking facility based at least in part on the estimatednumber of parking spaces that will be available at the selected parkingfacility when the requesting vehicle arrives at the selected parkingfacility; and transmit a location of the selected parking facility tothe requesting vehicle.
 17. The system of claim 16, wherein the at leastone second level manager is further configured to: determine an optimumtravel route between the requesting vehicle and the selected parkingfacility based at least in part on the requesting position and thelocation of the selected parking facility; and transmit the optimumtravel route to the requesting vehicle.
 18. The system of claim 10,further comprising: at least one third level manager being in a higherhierarchical level than the at least one second level manager andmanaging a region greater than the locality, wherein: the at least onesecond level manager comprises a plurality of second level managers;each of the plurality of second level managers is configured to:determine locality parking availability data comprising a number ofavailable parking spaces within the locality managed by the second levelmanager based at least in part on the facility parking availability datareceived from the plurality of first level managers in the localitymanaged by the second level manager; and transmit the locality parkingavailability data to one of the at least one third level manager, andthe at least one second level manager is configured to: receive localityparking availability data from one or more of the plurality of secondlevel managers in the region managed by the at least one third levelmanager; and determine a number of available parking spaces within eachlocality in the region based at least in part on the locality parkingavailability data.
 19. The system of claim 18, wherein the secondfrequency of the plurality of second level managers receiving thefacility parking availability data from the plurality of first levelmanagers is higher than a third frequency of the at least one thirdlevel manager receiving the locality parking availability data from theplurality of second level managers.
 20. The system of claim 18, whereinthe at least one third level manager is further configured to: receive arequest to locate an available parking space within the region managedby the third level manager from a requesting vehicle; receive arequesting position from the requesting vehicle corresponding to aposition of the requesting vehicle; obtain historical locality usagedata for the localities in the region managed by the third levelmanager; determine an estimated travel time for the requesting vehicleto arrive at each of the localities based at least in part on therequesting position; for each of the localities, estimate a number ofparking spaces that will be available within the locality when therequesting vehicle arrives at the locality based at least in part on theestimated travel time and the historical locality usage data; select oneof the localities as a selected locality based at least in part on theestimated number of parking spaces that will be available within thelocality when the requesting vehicle arrives at the selected locality;and transmit a location of the selected locality to the requestingvehicle.